ZTNA Demo — Story Flow
32-minute talk track. Dashboard-heavy. Pain first, architecture short, dashboard long. Natural language. Adapts to what the customer actually said in discovery.
The arc at a glance
01Open + agenda1 min
02Pain discovery (ask 4 questions, shut up)5 min
03aIntroduce the platform + walk all 6 connectivity patterns8 min
03bFrame the Zero Trust architecture (VPN vs ZT)4 min
04Bridge to dashboard30s
05Dashboard CORE — Overview + LIVE TUNNEL KILL DEMO5 min
06Dashboard PAIN-DRIVEN — pick the track that matches their Q4 answer8 min
07Compliance + audit story (tied to Logs view)3 min
08Close + specific next step2 min
09Back-pocket modules (off-script anytime)—
01 Open + agenda ~1 min
"Thanks for the time today. Here's how I want to spend the next thirty minutes. First five minutes I'm going to ask you a few questions — I want to make sure I understand where you are today before I show you anything. Then I'll walk through a quick architectural picture. Then we'll spend most of the call in the actual product looking at your data, your users, your traffic. I'll save room at the end for whatever you want to dig into. Sound good?"
Wait for them to say yes. That's the verbal contract.
02 Pain discovery — ask, listen ~5 min
Critically important: the answers here drive which dashboard track you pick in Step 06. Listen for which problem they emphasize most.
Question 1: "Walk me through what happens when your VPN concentrator hits capacity Monday morning. What does your team hear from users?"
- Tickets piling up, "VPN is slow"
- Drops on hotel Wi-Fi, mobile
- "It works in the office, not at home"
- Hardware refresh cycle frustration
Question 2: "How does a contractor get access today — start to finish?"
- Provisioning takes days (AD account, VPN profile, laptop ship)
- Helpdesk drains
- Forgotten accounts sitting in AD after projects end
- "We just give them a corporate laptop" (expensive, slow)
Question 3: "When was your last SOC 2 or regulatory audit, and were any findings tied to access or logging?"
- Logs scattered across VPN + firewall + IdP
- "We can't easily prove who accessed what, when"
- Privileged access reviews are manual / quarterly
- Compliance team flagging excessive standing access
Question 4 (the most important question): "If I gave you a magic wand for access — what's the one thing you'd change tomorrow?"
This answer determines which dashboard track you pick in Step 06.
- If they say "contractors" / "third parties" / "vendors" → Track A: Contractor & Identity
- If they say "performance" / "VPN is slow" / "MPLS costs" → Track B: Performance & Network
- If they say "audit" / "compliance" / "who accessed what" → Track C: Compliance & Visibility
"Okay — really helpful. A lot of what you just described maps to a specific architectural pattern. Let me show you the picture, then we'll get into the product and look at your real data."
03a Introduce the Cloudflare platform + connectivity ~8 min
Before you drill into the VPN-vs-Zero Trust argument, anchor who Cloudflare is. Most customers know us as "a CDN" or "DDoS protection." This is where you reset that framing.
🎬
Open this — first tab is "The full platform" (loads by default)
cf-demo-app.dustinburke23nc.workers.dev/vpn-vs-zerotrust
Tab 1: Cloudflare platform & connectivity (the merged platform intro + 6 on-ramps) · Tabs 2-5: the VPN-vs-Zero Trust deep dive (you'll use Tabs 2-5 in Section 3b).
Page opens on "The full platform" by default. Pause two seconds. Let the diagram register.
"Quick reset on what Cloudflare actually is, because most people know us from one angle. One platform, three things in scope. On the left — the people who need protection. Employees, contractors, AI agents now. Their devices, managed or BYOD. The locations they work from, HQ, branch, home, anywhere. On the right — what they're trying to reach. Your apps, your infrastructure, your networks. Everything in the middle is what we do."
Point at the orange hexagons in the center. Walk them slowly.
"Six capabilities, but they all share one network, one control plane, one set of logs. Zero Trust security — identity, access, posture. Network as a service — replacing MPLS, VPN concentrators, the works. AI security — for the new threats that didn't exist two years ago. Manage and compose — APIs, Terraform, dashboard. AI-powered platform — Workers AI, Vectorize, agentic infrastructure. And integrate and program — meaning you can extend any of this with code that runs at the edge."
The visual punchline: "Same network, same control plane, same logs. Not eight vendors. One platform."
Point at the three orange tiles along the bottom.
"Three promises that come out of this architecture. End-to-end visibility — every traffic flow, traceable. Consistency — your security policy enforced the same way no matter which on-ramp the user comes in on. And global distribution — 330+ cities, all running the same software, all doing the same job. That's the difference between SASE as marketing and SASE as architecture. Most vendors do half of this and partner for the other half. We do the whole thing on one network."
⚡ Tie-back to discovery
Glance back at what they said in pain discovery. If they mentioned contractors, point at the left column (Human users + AI agents). If they mentioned VPN cost, point at "Network as a service." If they mentioned audit findings, point at "End-to-end visibility." Make the platform personal to their problem.
⚡ If they push back: "this looks like a lot"
"Totally. The point isn't that you'd light all six up on day one. The point is that they're all on the same platform, so when you do need a second one, it's a toggle and not a procurement cycle. Today we're talking about Zero Trust. The rest is there when you need it."
Now walk the connectivity story — six patterns, one at a time
The platform diagram shows Cloudflare sitting between users and what they're reaching. The next question every customer has is: "OK, but how does the user actually get connected, and how does the server side hook in?" Answer that here, before they ask. Tell all six stories — three on the user side, three on the server side. Each one matches a real environment they're likely to recognize.
→ Still on Tab 1. After the platform intro, shift the customer's eye down to the 3 column diagram. Let them take in the layout — six cards, three per side, Cloudflare in the middle.
"Quick walk through both sides — because the next question is always 'how does the user actually connect, and how does the server side hook in?' Three on-ramps per side. Let me show you each one — they'll match up with whatever your environment looks like."
⚡ USER SIDE — 3 patterns
→ Click card U1 (Managed employee laptop).
"Pattern one — managed employee. Corporate laptop, fully under IT control. We push our WARP client through your MDM — Intune, Jamf, Workspace ONE — and the user never has to touch it. Once it's running, every request they make routes through the nearest Cloudflare PoP. Identity, posture, policy — all evaluated there, automatically. Single sign-on with your IdP, device posture check, and the policy decision is made at the edge before traffic ever reaches your apps. This is the default path for managed workforces."
→ Click card U2 (Contractor / BYOD).
"Pattern two — contractor or BYOD. The contractor's on their own laptop. You can't push an MDM agent. You can't reimage their machine. Two options. Either they install WARP voluntarily if you want full posture visibility, or they just open the app URL in any browser and log in with their own identity — Google, GitHub, email one-time PIN. No agent. No install. Nothing on their machine. Pair this with Browser Isolation if you want them to interact with internal data but never have it actually touch their device."
→ Click card U3 (Branch office / site).
"Pattern three — branch office. You don't ask every user at the site to install something. You connect the network from the edge router — Palo Alto, Fortinet, Cisco, Meraki, AWS VPN Gateway, whatever you have — to Cloudflare via IPsec or GRE. Two endpoints, shared key, done. Once that tunnel's up, every device behind that router gets policy enforcement. Laptops, phones, printers, IoT, all of it. This is what replaces MPLS and site-to-site VPN concentrators. If you're paying a telco for MPLS today, this is the conversation that ends that bill."
⚡ Anchor it to people they have
If they have a hybrid workforce: "So your San Francisco engineer with the corporate MacBook gets WARP. Your contractor in India on their own laptop gets the browser route. Your Atlanta office gets IPsec from their Palo Alto. Three different on-ramps. Same security policy hits all three."
⚡ SERVER SIDE — 3 patterns
→ Click card S1 (Single server or VM).
"Pattern one — single server. One app, one box. Could be an EC2 instance, a VM in your data center, a container, anywhere. You install a small connector called cloudflared on it. Three commands. It dials out to Cloudflare on 443 and holds a persistent connection. Nothing inbound from the internet. No public IP. No firewall port to open. No NAT rule. Your app becomes reachable through Cloudflare, and only through Cloudflare. Fastest path from 'we have an internal app' to 'we have a securely reachable app.' Five minutes."
→ Click card S2 (Whole VPC or subnet).
"Pattern two — whole VPC or subnet. When you've got mixed workloads in a VPC — fifteen apps, three database servers, a couple Windows boxes for RDP — and you don't want cloudflared on every one. You install WARP Connector on one server and tell it 'I represent this whole CIDR range.' Now every server behind it is reachable. No per-server agents. Great for legacy apps you can't modify, and for services that need long-lived TCP connections — databases, RDP, SSH, SAP, internal tools. Mesh is the variant when you want full peer-to-peer connectivity inside the private network."
→ Click card S3 (Data center or cloud region).
"Pattern three — whole data center or cloud region. Network-level integration. Same IPsec or GRE pattern as the branch office side, but on the server end of the network. Or — for very large or latency-sensitive deployments — CNI. Cloudflare Network Interconnect. A literal direct connection between your network and ours, bypassing the public internet. AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect, or a physical cross-connect in a peering facility like Equinix. Magic WAN orchestrates all of it together — branches, data centers, clouds, all glued together through Cloudflare's backbone. No MPLS, no SD-WAN appliances, no per-site mesh tunnels."
⚡ The architectural point worth landing
"Notice what's missing across all three server patterns. No public IP exposed. No firewall rule opened. No port forwarded. Every connection from your infrastructure to Cloudflare is outbound-only. The 'door' doesn't exist on the internet. Your apps stop being a target because they stop being addressable." Pause here. Let it land.
⚡ Tie-back to discovery on the connectivity story
If they said in discovery "we have a lot of EC2 instances" → emphasize S1 cloudflared.
If they said "we have a corporate data center with everything in it" → emphasize S3 Magic WAN / IPsec / CNI.
If they said "we have legacy apps and databases we can't touch" → emphasize S2 WARP Connector.
If they said "our contractors are everywhere" → emphasize U2 browser-only.
If they said "we're closing MPLS contracts" → emphasize U3 branch IPsec + S3 Magic WAN together.
"Okay — that's how both sides connect. Three user on-ramps, three server patterns, all converging on the same Cloudflare network in the middle. Same policy engine evaluates all of it. Now let me show you the specific architectural argument for Zero Trust, which is what you're actually here to talk about."
→ Click Tab 2 in the toolbar: "What VPN costs you".
03b Frame the Zero Trust architecture ~4 min
Open the page on "Side by side". Pause 2 seconds. Let them look.
"Before I get into the product, a picture. BEFORE — today's world with the VPN concentrator. AFTER — same diagram, Cloudflare's PoPs in the middle. Same people on the left, same apps on the right. Only the middle changes."
Click "What VPN costs you". Point at the red center box.
"Here's the thing — the middle today isn't one product. It's a stack. VPN box, firewall, cert store, MFA appliance. When you outgrow it, you don't replace one thing — you replace all of it. Three to five years, same conversation, same downtime weekend."
Point at "Your Cloud" on the right side. The CFO line.
"And this is the part that kinda gets forgotten — your own cloud has to take the same detour. Your contractor's in Singapore. Your VPN's in Virginia. AWS has a region next door to that contractor, but the traffic still goes all the way to Virginia and back. You're paying AWS to ship your traffic out, then paying again to ship it back in."
Click "What Cloudflare delivers". Point at the orange center.
"Same picture. Left side hasn't moved. Right side hasn't moved. The middle is a network now — over 330 cities. Eight inline checks: WARP, identity, access policy, gateway security, DLP, CASB, email security, browser isolation. Not eight vendors. One platform. Same logs."
⚡ Don't linger here. The dashboard is the main act.
04 Bridge to dashboard ~30s
"Okay, that's the picture. Now let me show you what this actually looks like running in production. I'm going to share my lab dashboard — it's got real tunnels, real users, real traffic. Then we'll connect what you see here back to the pain you described."
Switch tab to one.dash.cloudflare.com → Overview.
05 Dashboard CORE — everyone sees this ~5 min
Two stops everyone needs to see, no matter what they emphasized in discovery: the Overview (for context) and the Live Tunnel Kill Demo (for the wow moment).
5a — Cloudflare One Overview (~2 min)
Cloudflare One Dashboard → Overview
"This is the Cloudflare One Overview — the page you land on when you log in. It's designed to answer one question in ten seconds: is my Zero Trust deployment healthy and being used, or is it sitting there?"
Point at the counters at the top.
"These counters are the pulse check. Users in use — that's adoption. Active devices connected in the last seven days. Applications protected by Access policies. And Active Tunnels — outbound connections from my infrastructure to Cloudflare. I'm going to break that last one in a minute, on purpose."
If they ask about Targets (and they often do, especially if it's at zero):
"Good catch on Targets. A target is a specific machine you want to gate SSH or RDP access to — usually a server, a database box, a Windows machine. You register the IP, the hostname, the protocols it serves, and Cloudflare Access can then render a browser-based SSH or RDP session to it without anyone installing a client. It's specifically for what we call Access for Infrastructure — securing your internal servers the way you'd secure a web app. You'd use it when you have engineers, contractors, or vendors who need shell or desktop access to specific boxes — and you want every command logged, every session recorded, no standing VPN access."
⚡ When to point at this counter
If the customer's Q2 in discovery was about contractors or engineers needing SSH/RDP, this is the moment to say: "For the use case you mentioned earlier — that's literally what Targets are for. Let me show you the experience." Then you can jump to the /browser-ssh-rdp visual demo, or to a live SSH session if you have one registered.
Scroll to the "Your deployment" flow diagram.
"This part is new and honestly one of my favorite things on the platform right now. It's a flow diagram of how traffic actually moves through Zero Trust — users on the left, policies in the middle, applications on the right. Notice the shape? It's the same shape I just showed you on the architecture page. But this is your real data. Every line is an actual access request you can trace from person to policy to application."
⚡ If they emphasized compliance in discovery
This is your moment: "This is what your auditor sees instead of three different vendor exports stitched together in Excel."
5b — LIVE TUNNEL KILL DEMO (~3 min) — the centerpiece
This is the universal "wow" moment. Show it to everyone, every call. It demonstrates outbound-only architecture in a way no slide can.
Networks → Connectors → cloudflared
"Now I want to show you something that explains the architecture better than any diagram. I'm going to break my own tunnel, live, and you're going to see exactly what happens. Two things matter: what stays exposed, and what stops working."
Show the active tunnel. Open a browser tab to one of your protected apps — confirm it's reachable.
"Right now, this tunnel is connecting my private app from my home lab to Cloudflare. Notice — the tunnel is outbound only. There's no inbound port open on my firewall. There's no exposed IP on the internet. My app sits behind cloudflared, which dials out to Cloudflare and holds a persistent connection."
SSH into the box and kill the cloudflared process. Or use the dashboard to disable the tunnel.
"Watch what happens. I'm killing the cloudflared process on the origin. Now refresh the app."
Refresh the app tab. It fails to load.
"Access stops. And here's the important part — nothing is exposed. There's no IP an attacker could scan, no port still listening, no service to hit. The 'door' just doesn't exist anymore. That's the architectural difference: with a VPN, the network is always reachable and the VPN box decides who gets in. With us, there's nothing to reach in the first place. Cloudflare acts as the reverse proxy on behalf of an outbound-only tunnel."
Restart cloudflared. Show the app coming back online.
"Bring the tunnel back up — access restored. Zero firewall changes. Zero DNS changes. Zero exposed IPs."
⚡ Tie-back to discovery
If they mentioned firewall change requests or exposed services: "How many tickets does your team open per quarter to add or change firewall rules for new internal apps? With this architecture, that drops to zero."
"Okay — that's the architectural foundation. Now let me show you the part that solves the specific problem you mentioned earlier."
06 Dashboard PAIN-DRIVEN — pick a track ~8 min
Use the customer's Question 4 answer to pick ONE of these three tracks. Don't try to do all three in one call. If they straddle two, pick the more specific one. The others go in the back-pocket section if asked.
🧑💼 Track A — Contractor & Identity (8 min)
Pick this if they emphasized: contractors, third parties, vendors, BYOD, onboarding delays, account sprawl.
Stop 1 — Identity providers (~1 min)
Settings → Authentication → Login methods
"First thing I want to show — we don't replace your identity provider, we plug into it. Here's my lab — I have Okta, Google, GitHub, and email OTP all wired up. Different login methods for different user groups. Employees go through Okta. Developers go through GitHub. Contractors — I just send them an email and they get a one-time PIN. No AD account to provision."
Stop 2 — Applications & policies (~3 min)
Access → Applications → [pick a real app]
"Now look at how access is actually defined. Here's an internal app — my company wiki. Look at the policies attached to it. Two different policies, two different audiences. Employees need to be in this Okta group AND have MFA AND have WARP running. Contractors just need to be on this email allow-list — but their session runs through browser isolation, so they can view the page but can't copy data off it. Same app, completely different experience based on who you are."
Walk through a second app with stricter policy — e.g. an admin app with rule groups + device posture.
"This is a more sensitive app — the admin console. Look at the rule group. To get in, you need MFA but not SMS, you need to be in a specific group, you need WARP, and your device has to pass posture checks. CrowdStrike has to be running. Disk has to be encrypted. If any one of those changes mid-session, you're out."
Stop 3 — A real contractor in the system (~2 min)
My Team → Users → [find a contractor in your lab]
"Here's what a real contractor looks like in this system. They've never been in our AD. They authenticated with their own Google account. They're scoped to two applications. Their access expires automatically on December 31. When that date hits — every session terminates, the URL stops working, no cleanup ticket."
⚡ Visual cross-reference
Stop 4 — Browser SSH/RDP if engineering contractors come up (~2 min)
Access → Applications → [an SSH or RDP app]
"If you have engineering contractors who need real shell access — this is where it gets interesting. Watch this."
⚡ Track B — Performance & Network (8 min)
Pick this if they emphasized: VPN slowness, MPLS costs, branch office connectivity, global workforce, "users complain it's slow".
Stop 1 — Networks Overview (~1 min)
Networks → Overview
"This is where you orchestrate all the network-level pieces. Tunnels, IP routes, virtual networks, IP lists. Think of it as your software-defined private network — but it runs on our global backbone, not on rented MPLS circuits."
Stop 2 — Connectors and tunnel methods (~2 min)
Networks → Connectors
"Here are all the ways your network plugs into Cloudflare. Three patterns. cloudflared for a server-by-server software approach — easiest for cloud workloads. Mesh for connecting whole VPCs without touching every box. And Magic WAN for site-to-site, branch office to branch office."
Point at an active Magic WAN tunnel or IPsec connection if available.
"You can do IPsec from any standard router — Palo Alto, Fortinet, Cisco. You can do GRE for higher throughput. You can do CNI for a literal direct connection if you're already in our peering colos. Or WARP Connector if you can't touch the router. Mix and match per site."
Stop 3 — Resolvers & Proxies (~1 min)
Networks → Resolvers & Proxies
"And here's where DNS comes in. Your internal name resolution doesn't have to live on a domain controller anymore — Cloudflare can resolve your private names for users wherever they are. No more 'I have to be on the VPN just to look up an internal hostname.'"
Stop 4 — Traffic Policies + Live Firewall Demo (~3 min)
Gateway → Firewall policies
"Now look at the policy layer. This is your firewall, but as code, applied globally, evaluated at the edge. I'll show you a live one. Here's a policy that blocks crypto mining and malware domains across my whole workforce. Let me trigger it on my own laptop."
Open a known-blocked URL in your browser (with WARP on). Show it being blocked. Then go back to the dashboard.
"That request just got logged. Watch — Insights → Logs → Gateway."
Show the log entry that just appeared. Filter by user = you.
"There's the block, in real time. User, URL, policy that matched, action taken, location, device. This same log feeds your SIEM."
Stop 5 — Tie it back to global geography (~1 min)
"Every policy I just showed — and every check the user goes through — happens at the nearest PoP. Your Singapore contractor's traffic doesn't fly to Virginia and back. Your Dublin engineer hits Dublin. That's the architectural reason it's faster, not just a 'we made it faster' claim."
📋 Track C — Compliance & Visibility (8 min)
Pick this if they emphasized: audit findings, "who accessed what", standing privilege, SOC 2 / PCI / FedRAMP, log centralization.
Stop 1 — Insights → Logs (~3 min)
Insights → Logs
"Dashboards show trends. Logs show proof. This is the page your audit team will live in. Notice it's organized by control plane — Access logs, Gateway logs, Network policies — separate but co-located. You don't have to stitch three vendor exports together to answer 'who accessed what'."
Open Access logs. Filter by a specific user. Show their access history.
"Here's every authentication, every app reached, every policy decision, for one user. Time, location, device, identity provider used. Every entry is exportable — JSON, CSV, push to Logpush for your SIEM."
Switch to Gateway logs. Show a DNS or HTTP filtering decision.
"Same view, different control plane. This is your DNS and HTTP filtering. Every domain a user tried to reach. Every block. Every allow. You can audit by user, by category, by policy, by time. The thing that takes your team a week to assemble during an audit — that's just a saved filter here."
Stop 2 — Dashboards & reporting (~2 min)
Insights → Dashboards
"For executive reporting, you don't have to write a SIEM query. Pre-built dashboards. Top users, top blocked domains, top applications, geographic distribution, threat categories. Pin the ones you care about. Schedule them as recurring reports. Send them to your audit team automatically."
Stop 3 — User detail + posture history (~2 min)
My Team → Users → [pick a user]
"And for incident response — let's say there's a question about a specific user. Click into them. You see every session they've had, every device they've used, every app they accessed, every posture check that passed or failed. Their complete identity story, in one timeline."
Stop 4 — Service Credentials & non-human access (~1 min)
Access → Service Authentication → Service Tokens
"And one thing auditors love to find: machine-to-machine access. Service tokens. Issue a token to a CI/CD pipeline or a scheduled job, scoped to one app, with an expiration. Same audit trail as a human. No more 'we have shared API keys floating around.'"
⚡ Compliance certifications cheat sheet
SOC 2 Type II · ISO 27001 · ISO 27018 · ISO 27701 · PCI DSS Level 1 · FedRAMP Moderate · HIPAA-eligible. Logs exportable to Splunk, Sumo, Datadog, S3, GCS, Azure Blob via Logpush.
07 Compliance + audit story (universal) ~3 min
Quick reinforcement, no matter which track you picked. Stay in the dashboard.
Insights → Logs (briefly)
"On compliance — we're SOC 2 Type II, ISO 27001, PCI DSS, FedRAMP Moderate. Important part for you: every access decision is logged with who, what, when, from where. Exportable to your SIEM via Logpush. Splunk, Sumo, S3, Datadog — pick your destination."
"And the part your audit team will care about most — when a contractor's project ends and they're removed from the Access group, their session is terminated immediately. No cached VPN credentials. No 'they might still have a saved profile somewhere.' Gone."
⚡ If they're in a regulated geography
"We can pin your authentication and logging to a specific region — EU, UK, India — if you need to stay in-region for GDPR or local regulation."
08 Close + specific next step ~2 min
"Okay — that's the tour. Let me make sure I land where you need to land.
You mentioned [insert what they said in Question 4] as the biggest pain. We just walked through [insert track you picked] in the dashboard, which directly addresses that.
Two suggestions from here. First — I want to send you a short architecture doc tailored to your topology. Second — I'd like to set up a thirty-minute follow-up where we go deeper. Does Wednesday or Thursday next week work?"
⚡ Don't ask "what do you think?" That's the SE death sentence.
If they hesitate: "Most customers run this in parallel with their existing VPN for 30-60 days before cutting over. There's no rip-and-replace risk."
Or for CFO concerns: "If it helps your CFO, I can pull together a TCO comparison against your current stack — usually 40-60% reduction once you retire concentrator hardware and consolidate vendors."
09 Back-pocket modules — anytime, off-script —
If they ask "wait, isn't Cloudflare a CDN?"
"Same network, different jobs. CDN and DNS sit in front of your public website — like a bouncer at the door. Anyone can show up; we filter the bad stuff. Zero Trust is for everything that isn't public — internal apps, databases, dev tools. There's no door for the internet to knock on; users get verified by identity, then we let them in to the specific thing they need."
If they ask about phishing or email security
If they ask "how do we onboard internal servers?"
If they ask "what does the end-user experience look like?"
If they ask "is it really just another VPN client?"
"Same form factor, completely different architecture. The right question isn't 'is this another VPN client?' — it's 'what do I get to uninstall when I deploy this?' Most internal apps are web apps — users just hit a URL, no client needed. For the apps where you do install the client, it typically replaces your VPN client plus your SWG agent plus your DNS filter. The endpoint gets simpler, not more crowded."
If a network architect / SRE wants latency math
If they want one orchestrated tour (or for a future call)
10 Pre-call checklist do 5 min before
Open these tabs in your browser before the call. Do not open more than this — fumbling between tabs ruins the demo.
- Cloudflare One dashboard — logged in, sitting on Overview. This is your main canvas.
- Confirm the Overview counters all show non-zero — users, devices, targets, applications, tunnels. A zero next to anything makes the dashboard look empty. (See "Lab seed checklist" below if any counter is 0.)
- Pre-pick which app you'll demo — have it open in a second tab so you can hit refresh during the tunnel kill demo.
- SSH terminal into the cloudflared host, ready to kill the process (or know which dashboard toggle disables the tunnel).
cf-demo-app.dustinburke23nc.workers.dev/vpn-vs-zerotrust — the architectural anchor.- This cheat sheet in a separate window so you can glance without sharing screen.
⚡ Final pre-flight check
Before you join the call: verify the tunnel is up. Verify your IdP login works. Verify the app you'll demo is reachable. The tunnel kill demo is the wow moment — don't let "is anyone seeing the same screen as me?" be the first thing you say.
Lab seed checklist — fix the "0"s on your Overview
A bunch of zeros on the Overview makes the dashboard look unused. Do this once and it'll always look lived-in:
- If Applications = 0: Access → Applications → Add an application. Even a self-hosted test app you never use is fine — the counter just needs to be > 0.
- If Active tunnels = 0: Networks → Tunnels → ensure your cloudflared is running. This is the same tunnel you'll kill later, so it must be up.
- If Users / Devices = 0: install WARP on one device under your account email and let it enroll. Done.
Targets = 0 is fine. Don't fabricate a target just to make the counter non-zero. Targets are for Access for Infrastructure (SSH/RDP gating), and most customers haven't deployed that yet either — so it being zero is actually realistic. Address it conversationally in your Overview narration (see Section 5a) instead of seeding the lab.
You only have to seed the lab once. After that, the apps and tunnels you registered stay until you delete them.